In many multimaster database systems, data is stored in a group of databases, data changes may be made to any member of the group, and a data change made to one member is propagated to the rest of the group. Multimaster database systems typically implement either a synchronous or an asynchronous replication scheme for propagating a change made to one database to the rest of the databases in the group.
With some synchronous multimaster replication schemes, each change is applied to all databases in the group immediately or to none of the databases if one or more of the databases in the group cannot accept the change. For example, one of the databases may be offline or unavailable. Synchronous multimaster replication is sometimes achieved using a two-phase commit protocol.
In contrast, with some asynchronous multimaster replication schemes, a change made to a database is immediately accepted by the database but propagation of the change to other databases in the group may be deferred. Because propagation of changes may be deferred, if one or more of the databases in the group are unavailable, the available databases can still accept changes, queuing the changes locally until they can be propagated. For this reason, multimaster database systems employing an asynchronous replication strategy are sometimes considered to be more highly available than multimaster database systems employing a synchronous replication strategy. Unfortunately, asynchronous multimaster replication brings with it the possibility of concurrency conflicts that occur as a result of concurrent database changes made at multiple databases.
A concurrency conflict can arise in a multimaster database system when the same data is changed differently in two different databases before either one of those changes can be propagated to the other. For example, assume data representing a particular person's eye color is changed to “brown” in database A, and after that change but before that change can be propagated to database B, data representing the particular person's eye color is changed to “green” in database B. Without additional information, it is unclear which change is the correct change that should be adopted by all databases in the system.
Multimaster database systems employing an asynchronous replication scheme typically provide mechanisms for “deconflicting” concurrency conflicts. As used herein, the term “deconflict”, refers generally to detecting and resolving a concurrency conflict such that resolution of the conflict is eventually adopted by all databases in the system. In some cases, the multimaster database system may be able to automatically deconflict a concurrency conflict without requiring user intervention. In other cases, user intervention may be needed or desired to determine which of the concurrent changes should be adopted as the correct one.
It would be desirable to provide assistance to users in evaluating and deconflicting concurrency conflicts where user intervention is needed or desired.